A Change-Request-Management (CRM) system is used during development of a software system to record and track the changes which have been requested by the stakeholders (e.g., users, testers, developers, and designers) of that software system. It is common for multiple CRM repositories to be in use in a single organization. In some cases, this is because no one CRM repository has all the features needed by the organization. In other cases, this is because it takes a long time to transition all of the business processes and projects from one CRM repository to a different CRM repository, and so both CRM repositories remain in use for an extensive period of time. As a result, users that participate in multiple software development projects will often have to use multiple CRM repositories.
One approach to minimize training costs and user mistakes when a single user must interact with multiple CRM repositories is to host all of the CRM repository clients in a common GUI framework, but this can only address some generic aspects of the user interactions with the different CRM repositories. A deeper unification can be achieved when the CRM repositories provide an application programming interface (API). In this case, a single client can be implemented that can access multiple repositories, but this frequently leads to a “lowest-common-denominator” client that only provides functionality that is common to all of the CRM repositories.
In addition to the problems identified above there are several other important problems that are not addressed by a common GUI framework or a common client. In particular, there often are queries that must be run that require information from multiple CRM repositories, and there often are important relationships that must be captured and maintained between objects in different CRM repositories. In addition, executing these queries or traversing these relationships should be possible even when one of the required repositories is unavailable or unresponsive.